Hvordan angrer jeg 'git add' før jeg forplikter meg?

1
2
Neste
Du kan angre git add før du forplikter deg med
git reset 
som fjerner den fra gjeldende indeks (listen "om å bli forpliktet") uten å endre noe annet.
Du kan bruke
git reset
uten noe filnavn for å fjerne alle forandringer. Dette kan være nyttig når det er for mange filer til å bli oppført en etter en på en rimelig tid.
I gamle versjoner av Git tilsvarer kommandoene ovenfor git reset HEAD  og git reset HEAD henholdsvis, og vil mislykkes hvis HEAD er udefinert (fordi du ennå ikke har gjort noen forpliktelser i depotet ditt) eller tvetydig (fordi du opprettet en gren som heter HEAD, som er en dum ting du ikke burde gjøre). Dette ble endret i Git 1.8.2, så i moderne versjoner av Git kan du bruke kommandoene ovenfor selv før du gjorde ditt første forpliktelse:
"git reset" (uten opsjoner eller parametere) brukes til å feile når
du har ingen forpliktelser i historien din, men det gir deg nå
en tom indeks (for å matche ikke-eksisterende forpliktelse er du ikke engang på).
Dokumentasjon: git reset
|
Du vil:
git rm --cached 
Argumentasjon:
Da jeg var ny på dette, prøvde jeg først
git reset.
(for å angre hele innledningen min), bare for å få denne (ikke så) nyttige meldingen:
fatalt: Kunne ikke løse 'HEAD' som en gyldig ref.
Det viser seg at dette er fordi HEAD ref (filial?) Ikke eksisterer før etter første forpliktelse. Det vil si at du får det samme nybegynnerproblemet som meg hvis arbeidsflyten din, som min, var omtrent som:
cd til den flotte nye prosjektkatalogen min for å prøve Git, den nye hotnessen
git init
git add.
git status
... masse dritt ruller etter ...
=> Fan, jeg ville ikke legge til alt dette.
google "angre git add"
=> finn Stack Overflow - yay
git reset.
=> fatalt: Kunne ikke løse 'HEAD' som en gyldig ref.
Det viser seg videre at det er en feil som er logget mot at det ikke er nyttig i adresselisten.
Og at den riktige løsningen var der i Git-statusutgangen (som, ja, jeg gløste over som 'dritt)
...
# Endringer som skal begås:
# (bruk "git rm --cached  ..." for å avvikle scenen)
...
Og løsningen er faktisk å bruke git rm - cached FILE.
Legg merke til advarslene andre steder her - git rm sletter den lokale arbeidskopien av filen, men ikke hvis du bruker --cached. Her er resultatet av git help rm:
--cached
Bruk dette alternativet til å fjerne scener og fjerne stier bare fra indeksen.
Arbeidende trefiler, enten endret eller ikke, blir igjen.
Jeg fortsetter å bruke
git rm --cached.
for å fjerne alt og starte på nytt. Virket ikke skjønt, for mens du legger til. er rekursiv, viser seg at rm trenger -r å gjenskape. Sukk.
git rm -r --cached.
Ok, nå er jeg tilbake til der jeg startet. Neste gang jeg skal bruke -n til å tørke og se hva som blir lagt til:
git add -n.
Jeg zippet opp alt til et trygt sted før jeg stolte på git help rm om - cached ikke ødelegge noe (og hva om jeg feilstavet det).
|
Hvis du skriver:
git status
Git vil fortelle deg hva som er iscenesatt, etc., inkludert instruksjoner om hvordan du avspiller:
bruk "git reset HEAD  ..." for å avvikle scenen
Jeg synes Git gjør en ganske god jobb med å tøffe meg til å gjøre det rette i situasjoner som dette.
Merk: Nyere Git-versjoner (1.8.4.x) har endret denne meldingen:
(bruk "git rm --cached  ..." for å avvikle scenen)
|
For å avklare: git add flytter endringer fra gjeldende arbeidskatalog til iscenesettelsesområdet (indeks).
Denne prosessen kalles iscenesettelse. Så den mest naturlige kommandoen for å iscenesette endringene (endrede filer) er den åpenbare:
git scene
git add er bare et enklere å skrive alias for git-scenen
Synd det er ingen git unstage eller git unadd-kommandoer. Den aktuelle er vanskeligere å gjette eller huske, men det er ganske åpenbart:
git reset HEAD -
Vi kan enkelt lage et alias for dette:
git config --global alias.unadd 'reset HEAD -'
git config --global alias.unstage 'reset HEAD -'
Og til slutt har vi nye kommandoer:
git legg til fil 1
git scenefil2
git unadd file2
git unstage-fil 1
Personlig bruker jeg enda kortere aliaser:
git a # For iscenesettelse
git u # For ustaging
|
Et tillegg til det aksepterte svaret, hvis den feilaktig tilføyde filen din var enorm, vil du sannsynligvis merke at selv om du fjerner den fra indeksen med 'git reset', synes den fortsatt å oppta plass i .git-katalogen.
Dette er ingenting å være bekymret for; filen er faktisk fortsatt i depotet, men bare som en "løs gjenstand". Det vil ikke bli kopiert til andre arkiver (via klon, trykk), og plassen vil etter hvert bli gjenvunnet - men kanskje ikke veldig snart. Hvis du er engstelig, kan du løpe:
git gc - beskjære = nå
Oppdatering (det følgende er mitt forsøk på å fjerne forvirring som kan oppstå fra de mest oppstemte svarene):
Så, hva er den virkelige angrepet av git add?
git reset HEAD ?
eller
git rm --cached ?
Strengt tatt, og hvis jeg ikke tar feil: ingen.
git add kan ikke angres - trygt, generelt.
La oss først huske hva git add  faktisk gjør:
Hvis  ikke tidligere ble sporet, legger git add det tilhurtigbufferen, med sitt nåværende innhold.
Hvis  allerede ble sporet, lagrer git add det nåværende innholdet (øyeblikksbilde, versjon) i hurtigbufferen. I Git kalles denne handlingen fortsatt add (ikke bare oppdater den), fordi to forskjellige versjoner (øyeblikksbilder) av en fil blir betraktet som to forskjellige elementer: Derfor legger vi faktisk til et nytt element i cachen, for å være til slutt begått senere.
I lys av dette er spørsmålet litt tvetydig:
Jeg la feil inn filer ved hjelp av kommandoen ...
OP-scenariet ser ut til å være det første (ikke-sporet fil), vi vil at "angre" skal fjerne filen (ikke bare det nåværende innholdet) fra de sporede elementene. Hvis dette er tilfelle, er det greit å kjøre git rm --cached .
Og vi kan også kjøre git reset HEAD . Dette er generelt å foretrekke, fordi det fungerer i begge scenarier: det gjør også angre når vi feilaktig la til en versjon av et allerede sporet element.
Men det er to forbehold.
For det første: Det er (som påpekt i svaret) bare ett scenario der git reset HEAD ikke fungerer, men git rm --cached gjør: et nytt depot (ingen forpliktelser). Men egentlig er dette en praktisk talt irrelevant sak.
For det andre: Vær oppmerksom på at git reset HEAD ikke magisk kan gjenopprette det tidligere bufrede filinnholdet, det synkroniserer det bare fra HEAD. Hvis vår misviste git-add overskrev en tidligere iscenesatt, ikke-forpliktet versjon, kan vi ikke gjenopprette den. Derfor kan vi strengt tatt ikke angre [*].
Eksempel:
$ git init
$ echo "versjon 1"> file.txt
$ git legg til file.txt # Først legg til file.txt
$ git commit -m 'first commit'
$ echo "versjon 2"> file.txt
$ git legg til file.txt # Stage (ikke begå) "versjon 2" av file.txt
$ git diff - hurtigbufret fil.txt
-versjon 1
+ versjon 2
$ echo "versjon 3"> file.txt
$ git diff file.txt
-versjon 2
+ versjon 3
$ git add file.txt # Ups, vi mente ikke dette
$ git reset HEAD file.txt # Angre?
$ git diff --cached file.txt # Ingen forskjell, selvfølgelig. scene == HODE
$ git diff file.txt # Vi har ugjenkallelig mistet "versjon 2"
-versjon 1
+ versjon 3
Selvfølgelig er dette ikke veldig kritisk hvis vi bare følger den vanlige late arbeidsflyten med å gjøre 'git add' bare for å legge til nye filer (sak 1), og vi oppdaterer nytt innhold via kommandoen commit, git commit -a.
* (Rediger: det ovennevnte er praktisk talt riktig, men det kan fremdeles være noen litt hackete / innviklede måter å gjenopprette endringer som ble iscenesatt, men ikke begått og deretter overskrevet - se kommentarene fra Johannes Matokic og iolsmit)
|
Angre en fil som allerede er lagt til er ganske enkelt å bruke Git. For å tilbakestille myfile.txt, som allerede er lagt til, bruk:
git reset HEAD myfile.txt
Forklaring:
Etter at du har iscenesatt uønskede filer for å angre, kan du tilbakestille git. Hodet er filhodet i den lokale, og den siste parameteren er navnet på filen din.
Jeg har laget trinnene i bildet nedenfor for mer detaljer for deg, inkludert alle trinn som kan skje i disse tilfellene:
|
git rm --cached. -r
vil "un-add" alt du har lagt til fra din nåværende katalog rekursivt
|
Løpe
git gui
og fjern alle filene manuelt eller ved å velge dem alle og klikke på unstage from commit-knappen.
|
Spørsmålet er ikke klart stilt. Årsaken er at git add har to betydninger:
legge til en ny fil i iscenesettelsesområdet, og angre deretter med git rm -cached-fil.
legge til en modifisert fil i iscenesettelsesområdet, og angre deretter med git reset HEAD-fil.
Hvis du er i tvil, bruk
git reset HEAD-fil
Fordi det gjør det forventede i begge tilfeller.
Advarsel: Hvis du gjør git rm - hurtigbufret fil på en fil som ble endret (en fil som eksisterte før i depotet), vil filen bli fjernet ved git commit! Det vil fortsatt eksistere i filsystemet ditt, men hvis noen andre trekker deg, vil filen bli slettet fra arbeidstreet.
git-status vil fortelle deg om filen var en ny fil eller endret:
På grenmester
Endringer som skal begås:
(bruk "git reset HEAD  ..." for å avvikle scenen)
ny fil: my_new_file.txt
modifisert: my_modified_file.txt
|
Git har kommandoer for alle tenkelige handlinger, men den trenger omfattende kunnskap for å få ting riktig, og på grunn av det er det i beste fall kontraintuitivt ...
Hva du gjorde før:
Endret en fil og brukte git add., Eller git add .
Hva vil du:
Fjern filen fra indeksen, men hold den versjonert og igjen med uforpliktede endringer i arbeidskopien:
git reset HEAD 
Tilbakestill filen til den siste tilstanden fra HEAD, angre endringene og fjern dem fra indeksen:
# Tenk `svn tilbakevend ` IIRC.
git reset HEAD 
git kassa 
# Hvis du har en `` som heter ` ', bruk:
git checkout - 
Dette er nødvendig siden git reset - hard HEAD fungerer ikke med enkeltfiler.
Fjern  fra indeks og versjonering, og hold den ikke-versjonerte filen med endringer i arbeidskopien:
git rm --cached 
Fjern  fra arbeidskopi og versjonering fullstendig:
git rm 
|
Hvis du er på første gang og du ikke kan bruke gittilbakestill, bare erklær "Git konkurs" og slett .git-mappen og start på nytt
|
I henhold til mange av de andre svarene, kan du bruke git reset
MEN:
Jeg fant dette flotte lille innlegget som faktisk legger til Git-kommandoen (vel, et alias) for git unadd: se git unadd for detaljer eller ..
Ganske enkelt,
git config --global alias.unadd "reset HEAD"
Nå kan du
git unadd foo.txt bar.txt
|
Bruk git add -i for å fjerne nettopp tilføyde filer fra din kommende forpliktelse. Eksempel:
Legge til filen du ikke ønsket:
$ git legge til foo
$ git-status
# På grenmester
# Endringer som skal begås:
# (bruk "git reset HEAD  ..." for å avvikle scenen)
#
# ny fil: foo
#
# Usporede filer:
# (bruk "git add  ..." for å inkludere i det som blir forpliktet)
# [...] #
Å gå til interaktivt legg til for å angre tilføyelsen din (kommandoene som er skrevet på git her er "r" (tilbakestilling), "1" (første oppføring i listen viser tilbakestilling), "retur" for å gå ut av tilbakestillingsmodus og "q" (slutte):
$ git add -i
iscenesatt ustadisk sti
1: + 1 / -0 ingenting foo
*** Kommandoer ***
1: [s] tatus 2: [u] pdate 3: [r] evert 4: [a] dd untracked
5: [p] atch 6: [d] iff 7: [q] uit 8: [h] elp
Hva nå> r
iscenesatt ustadisk sti
1: + 1 / -0 ingenting [f] oo
Tilbakestill >> 1
iscenesatt ustadisk sti
* 1: + 1 / -0 ingenting [f] oo
Tilbakestill >>
Merk: foo er ikke sporet nå.
vendte en vei
*** Kommandoer ***
1: [s] tatus 2: [u] pdate 3: [r] evert 4: [a] dd untracked
5: [p] atch 6: [d] iff 7: [q] uit 8: [h] elp
Hva nå> q
Ha det.
$
Det er det! Her er beviset ditt, som viser at "foo" er tilbake på listen uten spor:
$ git-status
# På grenmester
# Usporede filer:
# (bruk "git add  ..." for å inkludere i det som blir forpliktet)
# [...]
# foo
ingenting lagt til å begå, men ikke-sporede filer til stede (bruk "git add" for å spore)
$
|
git remove eller git rm kan brukes til dette, med --cached flagget. Prøve:
git hjelp rm
|
Her er en måte å unngå dette plagsomme problemet når du starter et nytt prosjekt:
Lag hovedkatalogen for det nye prosjektet.
Kjør git init.
Opprett nå en .gitignore-fil (selv om den er tom).
Forplikt .gitignore-filen.
Git gjør det veldig vanskelig å gjøre git reset hvis du ikke har noen forpliktelser. Hvis du oppretter en liten innledende forpliktelse bare for å ha en, kan du etterpå git add -A og git reset så mange ganger du vil for å få alt riktig.
En annen fordel med denne metoden er at hvis du får problemer med linjeslutning senere og trenger å oppdatere alle filene dine, er det enkelt:
Sjekk den første forpliktelsen. Dette fjerner alle filene dine.
Så sjekk ut den siste forpliktelsen din igjen. Dette vil hente nye kopier av filene dine ved hjelp av de nåværende linjeavslutningsinnstillingene.
|
Kanskje Git har utviklet seg siden du la ut spørsmålet ditt.
$> git --versjon
git versjon 1.6.2.1
Nå kan du prøve:
git reset HEAD.
Dette burde være det du leter etter.
|
Merk at hvis du ikke spesifiserer en revisjon, må du inkludere en skilletegn. Eksempel fra konsollen min:
git reset 
fatalt: tvetydig argument '': ukjent revisjon eller sti ikke i arbeidstreet.
Bruk '-' for å skille stier fra revisjoner
git reset - 
Ustadierte endringer etter tilbakestilling:
M 
(Git versjon 1.7.5.4)
|
Slik fjerner du nye filer fra iscenesettelsesområdet (og bare i tilfelle en ny fil), som foreslått ovenfor:
git rm --cached FILE
Bruk rm --cached bare for nye filer som tilfeldigvis er lagt til.
|
For å tilbakestille hver fil i en bestemt mappe (og undermappene), kan du bruke følgende kommando:
git reset *
|
Bruk * kommandoen til å håndtere flere filer om gangen:
git reset HEAD * .prj
git reset HEAD * .bmp
git reset HEAD * gdb *
etc.
|
Bare skriv git reset, det vil gå tilbake, og det er som om du aldri har skrevet git add. siden siste forpliktelse. Forsikre deg om at du har forpliktet deg før.
|
Anta at jeg oppretter en ny fil, newFile.txt:
Anta at jeg legger til filen ved et uhell, git add newFile.txt:
Nå vil jeg angre dette tillegget, før du forplikter deg, git reset newFile.txt:
|
For en bestemt fil:
git tilbakestill my_file.txt
git checkout my_file.txt
For alle filer som er lagt til:
git reset.
git kassa.
Merk: kassen endrer koden i filene og går til sist oppdatert (forpliktet) tilstand. reset endrer ikke kodene; det tilbakestiller bare overskriften.
|
For å angre git add, bruk:
git reset filnavn
|
Denne kommandoen fjerner endringene dine:
git reset HEAD filnavn.txt
Du kan også bruke
git add -p
for å legge til deler av filer.
|
Det er også interaktiv modus:
git add -i
Velg alternativ 3 for å fjerne filer. I mitt tilfelle vil jeg ofte legge til mer enn én fil, og med interaktiv modus kan du bruke tall som dette for å legge til filer. Dette vil ta alt annet enn 4: 1, 2, 3 og 5
For å velge en sekvens, skriv bare 1-5 for å ta alt fra 1 til 5.
Gi iscenesettelsesfiler
|
git add myfile.txt # Dette vil legge til filen din i listen over å bli forpliktet
Ganske motsatt av denne kommandoen er,
git reset HEAD myfile.txt # Dette vil angreden.
så du vil være i forrige tilstand. Spesifisert vil være igjen i ikke-sporet liste (forrige tilstand).
Det vil tilbakestille hodet med den angitte filen. så hvis hodet ikke har det, vil det bare tilbakestille det.
|
git reset filnavn.txt
Fjerner en fil med navnet filename.txt fra gjeldende indeks, området "om å bli forpliktet", uten å endre noe annet.
|
git reset filnavn.txt
Fjerner en fil med navnet filename.txt fra den nåværende indeksen, området "om å bli forpliktet", uten å endre noe annet.
|
I Sourcetree kan du gjøre dette enkelt via GUI.
Du kan sjekke hvilken kommando Sourcetree bruker for å avvikle en fil.
Jeg opprettet en ny fil og la den til Git. Så avstod jeg det med Sourcetree GUI.
Dette er resultatet:
Unstaging filer [08/12/15 10:43]
git -c diff.mnemonicprefix = false -c core.quotepath = false -c credential.helper = sourcetree reset -q - sti / til / fil / filnavn.java
Sourcetree bruker reset for å avinstallere nye filer.
|
1
2
Neste
Svært aktivt spørsmål. Tjen 10 rykte for å svare på dette spørsmålet. Omdømmekravet hjelper deg med å beskytte dette spørsmålet mot spam og ikke-svar-aktivitet.
Er ikke svaret du leter etter? Bla gjennom andre spørsmål merket git versjonskontroll git-commit git-stage eller still ditt eget spørsmål.